home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20021006-20030409 / 000020_hvanclee@nyx.net_Thu Oct 17 10:04:59 EDT 2002.msg < prev    next >
Text File  |  2020-01-01  |  4KB  |  66 lines

  1. Article: 13783 of comp.protocols.kermit.misc
  2. Newsgroups: comp.protocols.kermit.misc
  3. Subject: Re: Problems transferring over ppp connection
  4. References: <1034801647.495773@irys.nyx.net> <aokm12$7lv$1@watsol.cc.columbia.edu> <1034815854.830840@irys.nyx.net> <aol3ol$sch$1@newsmaster.cc.columbia.edu>
  5. Organization: Nyx, Spirit of the Night
  6. X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
  7. From: hvanclee@nyx.net (Henry van Cleef)
  8. Originator: hvanclee@nyx.net (Henry van Cleef)
  9. Message-ID: <1034844239.214811@irys.nyx.net>
  10. Cache-Post-Path: irys.nyx.net!unknown@nyx3.nyx.net
  11. X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
  12. NNTP-Posting-Host: 206.124.29.6
  13. Date: 17 Oct 2002 02:43:06 -0600
  14. X-Trace: omega.dimensional.com 1034844186 206.124.29.6 (17 Oct 2002 02:43:06 -0600)
  15. Lines: 47
  16. Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!ord-feed.news.verio.net!stl-feed.news.verio.net!news.cc.ukans.edu!logbridge.uoregon.edu!HSNX.atgi.net!cyclone-sf.pbi.net!216.218.192.242!news.he.net!dimensional.com!pulsar.dimensional.com!omega.dimensional.com!not-for-mail
  17. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13783
  18.  
  19. In article <aol3ol$sch$1@newsmaster.cc.columbia.edu>,
  20. Jeffrey Altman <jaltman@watsun.cc.columbia.edu> wrote:
  21. >In article <1034815854.830840@irys.nyx.net>,
  22. >Henry van Cleef <hvanclee@nyx.net> wrote:
  23. >: In article <aokm12$7lv$1@watsol.cc.columbia.edu>,
  24. >: Frank da Cruz <fdc@columbia.edu> wrote:
  25. >: >In article <1034801647.495773@irys.nyx.net>,
  26. >: >Henry van Cleef <hvanclee@nyx.net> wrote:
  27. >: >: 
  28. >: >: The TCP/IP connection uses STREAMING, and I suspect that my problem
  29. >: >: lies in the fact that it's much faster than my modem setup can handle.
  30. >: >: What's the proper way to deal with this.
  31. >: >:
  32. >: >The culprit is most likely a lack of effective flow control.
  33. >: >
  34. >: Thanks for the quick response, giving me an idea where to look.
  35. >
  36. >I should point out that if the connection was truly using STREAMING
  37. >transfers then if even a single error was to occur, the transfer
  38. >would fail.  Therefore, I must assume tht STREAMING transfers are
  39. >not being used.
  40. >
  41. Jeffrey, you are absolutely correct on this.  I was thinking of what
  42. happens when I transfer between local machines on a network.  
  43.  
  44. I verified that RTS and CTS are being explicitly set in the modem init
  45. string.   Also played around with some of the pppd options.  What
  46. seems to have had an effect is disabling software compression, and
  47. it's obvious that wasn't buying me anything.  Netscape 4.76 has no
  48. trouble downloading on the same connection.  Locking everything to
  49. 18.2 KB had no effect with compression enabled, and trying to run with
  50. xon/xoff only made matters worse.  I'm still not completely satisfied
  51. that I've pinned things down completely, or that there aren't problems
  52. with the remote end.  Also, the Sun version of ppp that is in the
  53. 10/01 distribution wasn't really documented, and has a distinctly beta
  54. flavor to it.  I might try the iPlanet version, which is on the
  55. installation disks.  I also think that the public domain version on
  56. samba (2.4.1) will compile for Solaris and might be worth
  57. investigating.  However, I think that the ppp newsgroup is the place
  58. to pursue such questions.  My real question here was whether the flow
  59. control was supposed to be in the kermit running over ppp or in the
  60. pppd's, and I think you're saying that the pppd's are the place to
  61. look.  The same kermit objects run fine over a telephone link and over
  62. a 100baseT link through a hub between machines, using ssh.
  63.  
  64. Hank
  65.  
  66.